-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Variable number of G29 grid points (UBL, Bilinear) #26084
base: bugfix-2.1.x
Are you sure you want to change the base?
Variable number of G29 grid points (UBL, Bilinear) #26084
Conversation
132a833
to
f350939
Compare
Works for Bilinear G29 LRFB syntax with square beds and without BILINEAR_SUBDIVISION.
f350939
to
c8db766
Compare
00750dc
to
c75b8e5
Compare
I have added G29 parameters G29 probing points determination logic: By default, it will keep the spacing between points at (actually around) If user specifies If user specifies |
c75b8e5
to
2b34779
Compare
Support G29 N and M parameters to set number of points in X and Y (overriding spacing) and/or G parameter to set spacing overriding number of points up to Config limit.
2b34779
to
aaf1e19
Compare
The parameters |
I have noticed that |
Anyway, we already use I went ahead and added a commit to…
|
Other areas where this change will be taking effect include:
|
Just to address a few things that I noticed at first glance.
|
You should reuse the logic already implemented for LINEAR but extend it to BILINEAR.
I simply moved some lines around but tried to leave the logic the same. When calculations are made with Anyway, I'm done messing around and I'll get out of your way for a while as you work out the details. I assume you should be able to reuse the XY parameters that currently apply to LINEAR, but maybe you'll need to do it in a separate block. We'll see! |
Ok, just fixed my typos, and now I'll be scarce for a while! Hit me up on Discord if you run into any snags in any of the code affected by this option. You can go ahead and add |
c624e13
to
e6f1b07
Compare
9c65146
to
4f65466
Compare
How much wrong? Just not precise as with more points (but good enough for small area), or it will be completely wrong calculated? What about 2*(>=3) grid? |
That was a simplified and therefore misleading statement. It all depends on whether the state of your bed (probed area) can be described by just 2x2 points. Meaning there can only be linear tilt in each axis. 2 points in a single axis can describe linear gradient (slope) but cannot describe a wave (up, down, up). If you think about a large metal bed, it is unlikely that 2x2 points will be enough to produce a good mesh and can lead to a crash. But since this is a PR about variable grid points, the area that we are talking about can be as small as (for example) 5x5cm, which should be easily described by just 2x2 grid. |
c792921
to
37fb26b
Compare
37d77d6
to
aa44542
Compare
Description
Allows for variable number of grid probing points up to the number (per axis) specified in config file.
The logic to determine the number of grid points can be based on many things (menu config, GCODE,...), but for now the aim is to automatically decrease the number of points when probing small area and point spacing is smaller than specified in
Configuration.h
byGRID_MIN_SPACING
, which seems to be the issue that most people have with number of probing points.Requirements
Probe, G29 Bilinear Leveling
Benefits
It addresses a lot of user requests and also decreases the probing time on larger machines when printing smaller things.
It goes together well with G29 LRFB syntax.
Configurations
The proposed changes in
Configuration.h
are submited in the PR.Related Issues
Work In Progress
Todo Minimums:
subdivide_mesh
extrapolate_unprobed_bed_level
ToDo Possibilities:
Configuration.h
(is there any reason why there is a sanity check that requires min 3x3?In its current implementation Variable Grid Points work (math algos need to be checked) unless you want to use features from unchecked files mentioned below.
Extending Support and ToDo Files
Files that needs to be adjusted in order to fully support Variable Grid Points.
Without those adjustments, they should just fail gracefully and display NaN when showing value of grid point beyond the variable grid point limit (most of those changes concern UI printing leveling grid).
MESH_EDIT_MENU Support
G-code support
Utils
e3v2 Support
ExtUI Support
It looks like IA_CREALITY implements its own leveling and thus doesn't bother with
VARIBALE_GRID_POINTS
, but just to be sure...Asking for HELP
Verify that mathematical algorithms in
feature/bedlevel/alb/bbl.cpp
classLevelingBilinear
are correct.extrapolate_unprobed_bed_level
andextrapolate_one_point
line_to_destination.
virt_2cmr
,virt_cmr
,virt_coord
Verify that EEPROM data storing and retrieval is implemented correctly
bedlevel.nr_grid_points
is correctImplement e3v2 and ExtUI support since I don't have the hardware to test it with.